I will reformat the title to use the proper commit message syntax.

🚀 Thanks for opening this pull request!

Pre-merge checks and finishing touches

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Could you briefly describe the purpose?

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.51%. Comparing base (94cee5b) to head (de77d6b).
⚠️ Report is 1 commits behind head on alpha.

❗ There is a different number of reports uploaded between BASE (94cee5b) and HEAD (de77d6b). Click for more details.

HEAD has 8 uploads less than BASE

Flag	BASE (94cee5b)	HEAD (de77d6b)
	13	5

@@            Coverage Diff             @@
##            alpha    #9930      +/-   ##
==========================================
- Coverage   93.08%   86.51%   -6.57%     
==========================================
  Files         187      187              
  Lines       15275    15279       +4     
  Branches      177      177              
==========================================
- Hits        14219    13219    -1000     
- Misses       1044     2043     +999     
- Partials       12       17       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Adding metadata adds overhead and increase data transfer costs. Also, it's impossible to distinguish multiple servers as these IDs are static.

To address both, the metadata should be a Parse Server variable and only if the variable is set should the meta data be set for the driver. Also, is it possible to add a test?

Adding metadata adds overhead and increase data transfer costs. Also, it's impossible to distinguish multiple servers as these IDs are static.

To address both, the metadata should be a Parse Server variable and only if the variable is set should the meta data be set for the driver. Also, is it possible to add a test?

Sure I'll do that. We basically want handshakes sent to the server to contain metadata about the app that is using the driver so it appears in the server logs when the handshake completes. I'll add the variable and tests.

@mtrezza this is effectively the same change as meteor/meteor#13222. The main purpose is to help differentiate client connections in MongoDB's mongos/mongod logs, so that anyone reviewing their cluster's logs can trace connections more effectively back to the client that created it.

The added overhead here would be a handful of bytes, as some metadata is already being sent - this just adds a couple dozen additional bytes to that.

@alexbevi Someones use case should not have a mandatory cost implication for all others. We don't anticipate every possible use case to quantify the implication, nor do we guess someones resource pricing model, nor do we set an arbitrary pain limit for said implication.

For the same reason we strive for versatility. Allowing developers to set a custom value via an optional option caters to more use cases, e.g. identify server version, deployment, commit hash, etc. in MongoDB logs.

@alexbevi Someones use case should not have a mandatory cost implication for all others. We don't anticipate every possible use case to quantify the implication, nor do we guess someones resource pricing model, nor do we set an arbitrary pain limit for said implication.

For the same reason we strive for versatility. Allowing developers to set a custom value via an optional option caters to more use cases, e.g. identify server version, deployment, commit hash, etc. in MongoDB logs.

I think that's reasonable to make additional information transmission configurable. Would a simple default of the adapter name only (ex: parse_server_gridfs or parse_server_storage) and making it opt-out be a better approach?

Opt-in makes more sense to me for the reasons I mentioned. I can't think of a reason to make this opt-out and use a default value. This is an optional log enhancement which is unnecessary in architectures where Parse Server is the only DB client, which I think is the majority, and likely unwanted in production deployments due to the unnecessary overhead. Data transfer can be a significant cost factor in MongoDB Atlas for example, so when thinking about scale, I lean towards opt-in. Even if just a few bytes, think of a scenario where minPoolSize and maxIdleTimeMS repeatedly keeps closing and opening connections, transmitting the additional log data. We strive for more efficiency while giving developers the option to be more verbose in logs, hence I think this PR with opt-in is a good suggestion.

Also, enriching the logs with server identifier and version by default exposes information that may provide an additional attack surface for lateral movements. The server version is currently only accessible with the master key.